-
Notifications
You must be signed in to change notification settings - Fork 29.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
errors: make sure all Node.js errors show their properties #29677
Conversation
cf78c7e
to
fcef9d0
Compare
This improves Node.js errors by always showing the attached properties when inspecting such an error. This applies especially to SystemError. It did often not show any properties but now all properties will be visible. This is done in a mainly backwards compatible way. Instead of using prototype getters and setters, the property is now set directly on the error.
fcef9d0
to
aa3b02b
Compare
One question regarding |
I personally think we should, since it's an actual property and the user would otherwise not know about that. It's possible to check for the code in that case. It is of course somewhat redundant but I think for now we should just show both. |
@nodejs/collaborators This could use some reviews. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
It is not clear why some operations are done in a specific way. This should be clarified to potentially simplify the implementation.
@mcollina PTAL (I added a TODO comment as suggested by @jasnell #29677 (comment)). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Still LGTM
Wondering if this might be more breaking than we realize. Out of caution, here's a CITGM (with debian-8 unchecked for $REASONS): https://ci.nodejs.org/view/Node.js-citgm/job/citgm-smoker/2027/ (queued) |
'[Error [ERR_SCRIPT_EXECUTION_INTERRUPTED]: ' + | ||
'Script execution was interrupted by `SIGINT`] {', | ||
" code: 'ERR_SCRIPT_EXECUTION_INTERRUPTED'", | ||
'}', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why did this test in particular need to change? is there something unusual about how this test works?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The difference is that the code
property became enumerable. That seems important so that users become aware that it's an actual property, not only part of .stack
.
Mostly we just do not check what properties exist but only verify that specific properties contain specific values.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In other words, because no other tests inspect .stack
this way?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's not the stack that is changed here. It's the output when inspecting the error (e.g., using console.log
or util.inspect
). The reason is that only enumerable properties are inspected by default and others are ignored.
We rarely inspect errors in tests. Mostly we just check for the properties existence and their values. That also works with non-enumerable properties.
CITGM looks good. |
@nodejs/tsc What's the semver-ity of this? Patch? Major? Minor even? |
@Trott I would say it's a patch, since no property was added or removed and they are also writable and configurable as before. We might call it semver-minor due to the change in enumerable properties but it seems more like a fix to me. We do enumerable properties on other system errors and also on other error types. Just the |
Going to land as patch. semver-* label can always be added after landing if anyone disagrees. |
This improves Node.js errors by always showing the attached properties when inspecting such an error. This applies especially to SystemError. It did often not show any properties but now all properties will be visible. This is done in a mainly backwards compatible way. Instead of using prototype getters and setters, the property is now set directly on the error. PR-URL: #29677 Reviewed-By: Matteo Collina <[email protected]> Reviewed-By: Benjamin Gruenbaum <[email protected]>
Landed in 500720f |
This improves Node.js errors by always showing the attached properties when inspecting such an error. This applies especially to SystemError. It did often not show any properties but now all properties will be visible. This is done in a mainly backwards compatible way. Instead of using prototype getters and setters, the property is now set directly on the error. PR-URL: #29677 Reviewed-By: Matteo Collina <[email protected]> Reviewed-By: Benjamin Gruenbaum <[email protected]>
This improves Node.js errors by always showing the attached properties
when inspecting such an error. This applies especially to SystemError.
It did often not show any properties but now all properties will be
visible.
This is done in a mainly backwards compatible way. Instead of using
prototype getters and setters, the property is now set directly on the
error.
Note: the custom inspect function is necessary for the SystemError to keep the old getter/setter behavior intact .
Checklist
make -j4 test
(UNIX), orvcbuild test
(Windows) passes